Skip to content

fix(apps): run whoami and fleetdm always-on HA (KEDA min 2) - #1902

Closed
devantler wants to merge 1 commit into
claude/ha-vpafrom
claude/ha-keda-apps
Closed

devantler wants to merge 1 commit into
claude/ha-vpafrom
claude/ha-keda-apps

Conversation

@devantler

Copy link
Copy Markdown
Contributor

Stacked on #1901. The KEDA scale-to-zero apps — made HA where the app actually supports multiple replicas.

Always-on HA (min 2)

App Why it's safe
whoami stateless echo
fleetdm app tier is stateless (state in MySQL/Redis)

HTTPScaledObject replicas.min: 0 → 2, initial replicas 1 → 2. KEDA still owns the count; these stay exempt from the floor (the floor governs statically-declared replicas, not autoscaled ones).

Genuinely single-pod (stay as-is, documented)

App Hard constraint
hubble-ui per-pod connection state — streaming sessions bounce across pods
headlamp OIDC login state is in-memory per pod
actual-budget SQLite on an RWO PVC (single writer)
longhorn-ui max-1 admin dashboard

⚠️ Trade-off

This abandons scale-to-zero for whoami/fleetdm (always 2 pods, ~idle cost). The maintainer deliberately built scale-to-zero for these; revert per-app by setting the HTTPScaledObject min back to 0 if the idle cost outweighs the availability.

Validation: ksail workload validate passes for the changed files.

🤖 Generated with Claude Code

The stateless KEDA scale-to-zero apps that can run multiple replicas now
stay always-on at 2 (survives a pod/node failure) instead of scaling to
zero: whoami (stateless) and fleetdm (app tier is stateless; state lives in
MySQL/Redis). HTTPScaledObject replicas.min 0->2; initial replicas 1->2.

The other KEDA apps genuinely can't run >1 and stay single-pod:
  - hubble-ui: keeps per-pod connection state (streaming sessions bounce);
  - headlamp: OIDC login state is in-memory per pod;
  - actual-budget: SQLite on an RWO PVC (single writer);
  - longhorn-ui: max-1 admin dashboard.

These stay exempt from require-three-replicas because KEDA owns their
replica count (the floor governs statically-declared replicas, not
autoscaled ones). Comments updated to reflect HA-where-possible.

Trade-off: this abandons scale-to-zero for whoami/fleetdm (always 2 pods).
Revert per-app by setting the HTTPScaledObject min back to 0 if the idle
cost isn't worth it.

Validated: ksail workload validate passes for the changed files.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@devantler

Copy link
Copy Markdown
Contributor Author

Closing — KEDA scale-to-zero apps should keep min 0 (they're already drain-safe). Dropped from the stack.

@devantler devantler closed this Jun 8, 2026
@github-project-automation github-project-automation Bot moved this from 🫴 Ready to ✅ Done in 🌊 Project Board Jun 8, 2026
@devantler
devantler deleted the claude/ha-keda-apps branch July 16, 2026 21:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

1 participant